Bolo C 1987-1992 Stuart Cheshire <cheshire@cs.stanford.edu>
Preface
~~~~~~
I think I have to explain to some people what beta test means. Beta test means that you get to see a new program before it is publicly released.
In exchange for this, I would appreciate some feedback concerning bugs you find. Now stop me if I am being unreasonable, but I am a little unhappy about all the people out there are who are still running version 0.90 and telling their friends to do the same, because apparently I introduced some new bugs in the process of adding sound effects and other features to version 0.93. Now I don't mind you bitching about bugs, as long as you tell ME about them, instead of me having to find out third hand from someone else. What's the matter -- you scared of e-mail or something?
Anyway, thanks to the people who have sent me some kind of feedback. Bolo is continuing to improve because of you.
Please be aware that at this stage what I am interested in hearing is reports of crashes -- ie important things to fix. EVERYONE has their own ideas about how I should change the user interface -- and I don't have time to reply to all of those messages. Be assured that many improvements for the user interface are planned as soon as I have time.
Notes
~~~~~
Bolo is still in beta test, although no great problems are expected.
The Bolo manual should accompany this Readme file. If not, you can obtain it, and up-to-date copies of all the other files, by anonymous ftp from bolo.stanford.edu.
The manual is in Microsoft Word format (Word 4 or 5). Sorry if you don't have it. I'll convert it to DiskPaper if Farallon give me a free copy.
If you want sound effects, put the BoloSounds file in the same folder as the Bolo application icon. If you want to save disk space, you can chuck the BoloSounds file and Bolo will still work. If you do this, you can also reduce Bolo's memory allocation to about 450K instead of 950K.
On Macs with screens larger than the original 512x324 'compact' Mac screens, I have a column of debugging information down the right-hand side of the window. Do not be alarmed. If all goes well and no horrific bugs are found, then it will be gone soon. Also, the zoom box of the window is there for my debugging. Clicking it does not zoom the window. It blanks it, so that I can check that the graphics routines are redrawing the correct areas of the screen.
The game benefits hugely from colour. Even if you play it on a black-and white Mac, try to get a look at it on a colour Mac first, and it should help make it more obvious what the various visual elements on the screen represent. Improvements to the monochrome graphics are planned.
Bolo is 32 bit clean, System 6/7 compatible, A/UX compatible, IIFX and Quadra compatible, multiple monitor compatible, 32bit QuickDraw compatible, DirectColor compatible, etc. etc. etc. I'm not sure about Virtual Memory, but it hasn't crashed yet. I already use the Deferred Task Manager for my interrupt routines, but I need someone who is an expert on VM to tell me if there is any other magic that I need to do.
Bolo was written entirely in Think C 5 (with a little inline assembler) accompanied by Max Lyth's excellent Think C utility CMaster. See the end of this file for more details.
Frequently Asked Questions, and Frequently Suggested Ideas.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.."Why don't you generate a new random map for each new game?"
Well, if you can write me an algorithm which will generate plausible looking interesting maps, then I might consider using it. You know what the different terrain types are, so go for it if you think you can.
.."Why don't you produce a map editor so that I can create my own maps?"
I will, but it is not the highest priority at the moment. Finishing the game itself is the highest priority.
.."Why don't you allow the tank turret to rotate relative to the tank body?"
Many people request this, so that (no affront intended to the quotee) "when driving by a pillbox, you could drive on road and blow it away by shooting to the side." This is precisely the point. To maintain the balance of the game I would then have to make pillboxes more powerful to compensate for your enhanced abilities. The difficulty of shooting a pillbox, or an enemy tank, would be exactly the same, except that you'd have to do more finger ballet on the keyboard to achieve the same results. This would just make the game even harder on novice players (as if it wasn't hard enough already).
.."Why can't the tank reverse?"
Same reason as above. It adds more buttons and adds complication to the game without making it any better. As it is now, if you cleverly catch someone carelessly hanging around on a narrow bridge or beside a lake, you can shoot them and knock them into the water, where they will be almost helpless for you to easily finish off. If they had reverse they could quickly reverse out of the water and escape. In this game, if you are stupid, you pay the penalty. There are no second chances, no smart bombs, and no hyperspace. Watch your back.
.."I turn on 'Background Sound' but there is no music."
Background sound does not mean music, it means Bolo continues to make sounds when you put it in the background to work with some other application. Read the Balloon help!
.."Why does the game occasionally seem to freeze for a second or two for no reason, and for about ten seconds when someone quits?"
The game copes with lost network packets, and lost players, but not very well. Don't worry, improving that is high on the list of priorities.
.."I really like Bolo except for the fact that I need to have friends to play it with. Why don't you make a single player version?"
Two answers:
1. If you want a single player game, there are hundreds, if not thousands, already. Play one of those instead. I'm writing a multi-player game.
2. When Bolo is finished, I am going to release it as a library, so if you want to try writing your own Artifical Intelligence routines to drive enemy tanks, be my guest. If it works, we could have a new kind of Bolo Turing Test, where you have to play against various opponents and decide if they are human or not.
If you send me e-mail about any of the above topics before I have finished the real work of getting the program finished and debugged then don't expect a reply.
Priorities for next release. Sorry, didn't have time to do them for 0.95.
~~~~~~~~~~~~~~~~~~~~~
..Find out why Bolo occasionally makes garbage screeching sounds. I have a suspicion it is a Sound Manager bug -- bad interaction with AppleTalk -- but I have to get real evidence before I make any accusations.
..Improve key setting dialog box, and save settings in preferences folder.
..Fix Bug: key setting dialog box doesn't work if the Caps Lock key is down.
..Ability to save the current game.
..Optional floating name tags attached to tank characters on the screen so you know who the players are.
..Remove column of debugging information.
.."News wire" service giving you help ("You cannot build there because you need to farm some trees first") and news ("Dane has just stolen one of Stuart's refuelling bases"). This should liven the game up a bit and keep everyone on their toes.
..Must radically improve message system, so that you know who the message is coming from, so that you can edit the text before you send it, so that text typed from different people does not get interleaved etc. etc. etc. This will include fixing the strange alternating black and white characters which occur on some Macs.
..Protocol to allow you to quit the game. At the moment, when you quit, the other machines in the game enter the catasrophic failure recovery mode to re-establish communication without you. If two players quit simultanously then it is possible that the game could be partitioned into two smaller separated games.
..Redesign some characters to make it more comprehensible on Black and White screens.
..When you quit the game, any mines that only you know about disappear too. This should be fixed.
..Should make Bolo scan all zones looking for players. It is too tedious to do it by hand every time, especially when there are dozens or even hundreds of zones.
Still to be done:
..Add UDP/IP communication option to allow games to span areas greater than a single AppleTalk internet. (I'm not making any promises about making games span the whole world yet).
..Bug reported where sometimes (for no understandable reason) you cannot repair a broken pillbox. Cannot reproduce this, so I intend to ignore it unless my loyal beta testers can give me any more insight, or at least more reports of its occurrence.
..Ability to pick up and transport refueling bases like the way you do with pillboxes.
..Maybe make bases shoot back at enemy tanks (like pillboxes) when they are attacked.
..Ability to switch to remote view from a base, like the way you can with pillboxes.
..Option to display a complete (small scale) overview of the island, which will allow you to see what it happening in areas near bases and pillboxes that you own, but other areas will be blank.
..Fix slight bug in window dragging code on multiple monitors.
..Idea: numbers next to ammunition indicators (both tank and base) to give a precise count.
..Improve the Game Start dialog box to the new System 7 style -- TAB to switch panes in the dialog box, letter keys to select zones and players etc. (like the new Chooser).
..Some kind of perimeter to stop you sailing out on a boat miles from the island so that you cannot find your way back.
..Try to make the game a little easier on beginners. You already start the game with full shells, full mines, full armour, and a free boat, but perhaps this is not enough. Every design decision in the game was made with the goal of long lasting interest in mind. The game is intended to be very open and unrestrictive, in that there a lot of ways to play it, but this can make the initial learning curve very steep because it is not obvious what you are 'supposed' to be doing. I am trying to think of ways to soften the learning process without making the game any less fun for the enthusiasts who play it for hours at a time. These are my loyal users (and I am one of those enthusiasts too) so they will always remain my top priority. I refuse to write a "looks pretty today, boring tomorrow" game. This is what I would have to do if I was selling it commercially.
..Some kind of concept of 'winning' the game. At the moment, people just play until one player or team of players have such an overwhelming superiority that the others concede defeat and go for a drink instead. It might be better to have a formal definition of when the game ends.
..It may be worth looking into identifying and rewriting some of the most critical code to make it run a bit faster on slower models: Mac Plus, SE, Portable, Classic, PowerBook 100 etc.
..Digitized voice communication- battlefield radio (probably only feasible with ethernet or faster).
..Design a new screen layout to fill a Mac II screen and show larger graphics. This obviously involves redesigning all the graphics characters, since just enlarging them will look unacceptably 'chunky'
..Map editor to let you create your own maps -- a pair of large islands connected by a narrow causeway of land, an archipelago of small islands connected by bridges, a forested jungle island, a Manhattan street map, etc. Suggestions welcome.
..Two different game 'modes' -- a tournament mode with strict rules, and an easy 'open-game' mode where players can come and go as they please, so that an open game can run for days on the network with an ever changing collection of players.
..Possibility of an option to start a new game instead of joining the one which is already in progress on the network.
Still to find out:
..Why Bolo runs so slowly on an Apple 8*24GC display card with the acceleration turned ON. For now, until I fix it, you will just have to turn acceleration OFF to run Bolo.
..How do I find out 'myzone' under AppleTalk Phase I?
..Something for the "set keys" dialog: Given a 'key code', how do I find out what 'character' that corresponds to, so that I can display it nicely for the user? Even better would be the full pictograms to correctly represent modifier keys, keys on the numeric keypad etc.
..After Dark problems.
1. After Dark has something they call the SystemIQ (TM) activity monitor, or something like that. If you turn this 'feature' on, After Dark apparently detects that Bolo is running, drawing graphics, growing trees, talking to other machines on the network etc, and decides that it should not go to sleep. If this is not what you want, then don't turn this 'feature' on. If someone can tell me a workaround, I'll do it.
2. Bolo draws 'through' an After Dark screen saver. This is because Bolo can write directly to screen memory, and does so correctly according to the Apple guidelines. Bolo correctly copes with multiple monitors, different bit depths etc. and copes when the window is partially or completely obscured, by checking the windows 'visRgn' which tells it which part of the window is currently visible on the screen. After Dark does not update the window's visRgn correctly, so Bolo has no way of knowing that its window should have been obscured by the screen saver display. Until someone tells me how I am supposed to know that After Dark is running, the only solution is to use one of the many other screen savers for the Mac, all of which work fine.
Credits
~~~~~~
..Original game concept: James Everard and Stuart Cheshire
..Programming: Stuart Cheshire
..Map and graphics character design (original BBC micro version): James Everard
..Macintosh programming environment: Symantec's Think C and Max Lyth's CMaster.
..Sound effects and Sound manager expertise: Kevin Marks and Maf Vosburgh
..Voice of dying man: Maf Vosburgh
..Sample code to help me see how to handle multiple monitors: Steve Newman
..New colour scheme for graphics on Macintosh: Pavani Diwanji
..Miscellaneous encouragement and advice about VBL tasks: Bernhard Wieser
..Writing the ace Macintosh FTP server that allows me to distribute Bolo: Peter Lewis
..Major stress testing and bug reporting for low-end Macs (Plus & SE): David Hsu and Brian Quirion (aka antz aka Jondolar)
..Immeasurable help in spreading the word at Apple and getting Bolo stress tested on Quadras and under A/UX and on large AppleTalk networks and lots of other things: Brian Wilson.
..Special mention for good ideas regarding network recovery: Kevin Marks
..Special mention for really evil way of killing a pillbox: Dane Spearing
..Special mention for managing to win against six opponents despite total inability to ever shoot at an enemy tank and hit it: Tom Costello
..Testing and encouragement: Dane Spearing, Mark Visokay, Tom Costello, Bob McDaniel, Jeremy Doig, Matt Rollefson, Michele Carvalho, and anyone else whom I may have forgotten; let me know so I can add your name to the list.
..Thanks are due to my PhD advisor Dr Cheriton for the freedom he allowed me to spend some time working on this as well as the true research which is what he is paying me for.
About the author
~~~~~~~~~~~~~
Stuart Cheshire is a PhD student working at Stanford University in David Cheriton's Distributed Systems Group.
Bolo was first conceived as a two player game by Stuart Cheshire and James Everard in Cambridge in the summer of 1987. It soon grew into a 16 player distributed game running over 4800 baud RS423 connections by early 1988, but unfortunately there was never any opportunity to run it with more than 8 machines.
In January 1989 work started on porting to the Apple Macintosh, but was not completed.
In the autumn of1990, after nearly two years break, work resumed on porting to the Apple Macintosh. This continued sporadically for over a year, reaching the first really playable version just before Christmas 1991.
Bolo continued to need the author's continuous attention to keep a game running, like a sick aircraft being nursed along by a skilled pilot, until April 1992, when it finally made its first unassisted flight, staying airborne for over 48 hours.
The saga continues...
Release notes, in reverse order
~~~~~~~~~~~~~~~~~~~~~~~~
0.95a, 0.95b, 0.95c etc. minor (but important) bug fixes to be incorporated into 0.96 eventually. 0.95c should work better on low-memory Macs because it refrains from stupidly loading ALL the sounds it can until there is no memory left; instead it ensures that at least 50K is left free for other uses such as dialog boxes etc.
0.95. 27th May 1992.
~~~~
..Finally, I think I have found the cause of the loss-of-ownership bug. I believe it is an obscure timing error which only occurs on LocalTalk -- not on Ethernet, which is why I could never reproduce it on my own machine. I *think* I have fixed it now, so definitely let me know please if it happens again.
..BoloSounds now has its own icon. You will have to trash ALL old Bolo files on your hard disk (and remember to empty the trash), drag the new files onto your hard disk, and then restart your Mac with Command-Option held down to rebuild the desktop file.
0.94. 25th May 1992.
~~~~
..Fixed minor bug in startup code when you are the first player in a game.
..Fixed bug where sometimes your replacement combat engineer would not parachute in to the right place.
..Bolo now throws up a dialog box to stop you quitting accidentally when you hit Cmd-Q by mistake.
..Bolo now allows you to reclaim your old posessions if you rejoin a game you recently left. You must enter EXACTLY the same name, and check the "Reclaim old posessions" checkbox.
..Slightly changed the way cursor-keys scroll the screen. You now cannot scroll hostile objects (tanks and pillboxes) off the screen unless you turn off AutoScroll first (Bolo menu). If you turn off AutoScroll then you may get no warning of baddies approacing from your 'blind side', so be careful. If you try to drive your tank completely off the screen, then AutoScroll is automatically turned back on.
0.93. 13th May 1992.
~~~~
..Reduced network packet rate so it should run better on Classics etc. now.
..Fixed major bugs in code for non-Colour QuickDraw Macs (Plus, SE, Classic etc.).
0.92. 11th May 1992.
~~~~
..Fixed bug where sometimes when you fired, a trail of multiple shell images could appear.
..Workaround for a bug in QuickMail which destroys other programs' network connections.
..Improved startup time on large AppleTalk networks (over 100 zones).
..Improved performance under A/UX on low-end Macs.
..Fixed a bug where chains of mines could continuously explode.
..Added sound effects.
..Improved screen scrolling algorithm (I think).
..Fixed odd address error on 68000 machines. God I hate those.
..Added a bit of Balloon Help for the menus.
0.91. 1st May 1992.
~~~~
..Fixed bug where players who quit could leave 'phantom' tanks on other players' screens.
..Fixed bug where players joining a running game could enter in in "request alliance" mode, which is undesirable because you should have to explicitly request an alliance.
..Fixed bug where a malformed packet on the network could get the game into a bad state where it got stuck in a loop with interrupts disabled.
..Fixed a bug that made tanks in forest completely invisible, even when got so close that you crashed into them. Tanks in forest now become visible when you get close enough to see them (about 3 map squares away).
..Added option to reconfigure the control keys.
0.90. 24th April 1992. First genuinely public release
~~~~
..Fixed it so after you die it won't put your new tank right next to a pillbox.
..Got rid of the five free shells every tank got when it restarted. Now you get some free shells, but it decreases as the game progresses until finally you get none. If one player controls all the refuelling bases then the game is over. No more endless dragging out the end of the game. If you have no refuelling bases (and noone will make you their ally) then you have no shells. End of game.
..Modified the 'easy start' feature intended for beginners. Giving your first tank 40 shells, 40 mines and a free boat was intended to make the game slightly less impossible for first time players. What happended was that players just kept quitting the game and rejoining to get lots of 'first' tanks. Now the easy beginner mode only lasts until the first pillbox on the map is killed. After that the game is on, and no more free lunch.
..When you shoot a base to capture it from another player, its appearance changes to let you know that you have killed it.
..When you quit the game, any personal posessions you have revert to neutral ownership. Any player joining the game later, and being assigned your old player number will not 'inherit' all your old property.
..When you layed mines using the TAB key, sometimes your allies could not see the mines. This is fixed.
..When you are killed it now waits slightly longer before blanking the screen so that you can see what it was that killed you.
..Added a count of how many other players you have killed,
..and a count of how many times you have been killed.
..Added "Players" menu so you can see who the other players are.
..Added very simple message system to allow players to type messages to each other.
"Dangerous" version. Wednesday 22nd April 1992. First (semi)public release.
~~~~~~~~~~~~~~~~
To my complete amazement, everything worked almost perfectly. There were minor logical flaws which people managed to discover and exploit, but no serious bugs in the network software, and no crashes. This version ran continuously for over 48 hours at Stanford with a varying set of players until it was replaced by version 0.9 on Friday 24th April.
Bolo would have taken twice as long to write if it were not for Max Lyth's CMaster, an invaulable programmers' utility for Think C.
CMaster provides too many useful features to list here, but my favourite is a popup menu of functions defined in the window you are editing, so that you can navigate around large files MUCH faster than you could otherwise. This allows you to structure your program how you want, instead of being forced to subdivide modules simply because they are too big for you to cope with.
It also gives live scrolling when you drag the scroll box, feature to place marker points in a file, and when you open any file it restores it to extactly the position, size and shape it was in when you closed it last, even putting the scroll bar and insertion point back where they were.
I could write forever about the huge list of things it does and how great it is, but I must stop somewhere, so here is the address where you can order it:
Jersey Scientific, Inc
545 Eighth Ave 19th Flr
New York, NY 10018
USA
Telephone: USA (212) 736 0406
Fax: USA (212) 947 4981 or (201) 464 3458
electronic mail: jersci@applelink.apple.com
I have no connection with Jersey Scientific other than gratitude for the hundreds of hours of my precious time they have saved with this product.
